返回设计模式博客目录
|
第一篇:单一职责原则
第二篇:开闭原则
第三篇:里氏替换原则
第四篇:依赖倒置原则
第五篇:接口隔离原则
第六篇:迪米特原则
请实现一个简易的图片加载器(ImageLoader)?
以下是一个新手实现的图片加载器源码:
测试代码:
上述代码虽然满足功能需求,但是所有的功能代码都写在一个类中,这样随着功能的增多,ImageLoader 类会越来越大,代码也越来越负责,图片加载系统就越来越脆弱……
我们可以参照单一职责原则,把 ImageLoader 拆分一下,让各个功能独立出来:
- ImageCache:用于处理图片缓存。
- ImageUtil:图片工具类,如获取图片大小、下载图片等。
改进后的源码:
ImageLoader.java
ImageCache.java
ImageUtil.java
单一职责原则概述
应该有且仅有一个原因引起类的变更 (There should never be more than one reason for a class to change)。
单一职责原则为我们提供了一个编写程序的准则,要求我们在编写类,抽象类,接口时,要使其功能职责单一纯碎,将导致其变更的因素缩减到最少。
如果一个类承担的职责过多,就等于把这些职责耦合在一起。一个职责的变化可能会影响或损坏其他职责的功能。而且职责越多,这个类变化的几率就会越大,类的稳定性就会越低。
在软件开发中,经常会遇到一个功能类 T 负责两个不同的职责:职责 P1,职责 P2。现因需求变更需要更改职责 P1 来满足新的业务需求,当我们实现完成后,发现因更改职责 P1 竟导致原本能够正常运行的职责 P2 发生故障。而修复职责 P2 又不得不更改职责 P1 的逻辑,这便是因为功能类 T 的职责不够单一,职责 P1 与职责 P2 耦合在一起导致的。
附:动态权限申请代码
|
|
PermissionListener.java